物流系统的设计总结

       本人供职于某电商公司的物流部门，负责相关物流信息系统的开发，其中最重要的系统就是为了对接各大快递公司，从各家快递公司获取订单的物流轨迹。刚开始公司为了省事是通过付费方式统一从快递100获取各大家物流公司的物流轨迹，但由于订单数量比较大，每个月都要支付一笔不小的费用给快递100，费用是不超过10万则每单0.1元，超过则每单0.05元，系统每天调用快递100的单量大概是100万，这样每天就需要支付5.5万的费用。为了节省费用，选择直接对接各大快递公司，这样每年可以为公司省下2000万的费用。

     该物流系统具有以下特点

1.对接的快递公司数量多

    目前主流的快递公司有差不多30家，包括申通、圆通、汇通、中通、邮政等快递公司，商家发货单量最多的快递公司是四通一达。

2.各家快递公司的接口各异

    有些是使用JAVA接口，比如京东，但大部分是使用HTTP接口，比如申通。接口的返回格式也不同，有些是使用XML格式数据，大部分是使用JSON字符串。物流轨迹的状态不一样，物流轨迹的状态主要有揽收、在途、送货、签收、拒收、异常件。但有些快递公司是没有揽收、拒收或异常件的，需要对物流轨迹的状态进行统一转换。有些快递公司是没有轨迹的状态，只有描述，这样我们就需要从描述中识别出状态，由于各种状态不统一，有些随意，所以经常会出现错误识别的问题，比如轨迹是拒收状态的，但我们识别成签收，或签收状态我们识别成拒收，这会影响业务，比如财务退款就是根据拒收判断的。为了解决这种频繁的错误识别问题，我们使用JS脚本来识别轨迹状态，再把JS脚本放入JAVA中的JS引擎里面执行，这样系统升级时不需要频繁启动，只需要更新数据库里面的JS脚本就可以了。

3.系统数据量庞大

    公司每天的订单量有一百多万，每个订单产生的物流轨迹大概是5~10条，每天产生的轨迹数量有几百万。按每天一百万单，每单5条物流轨迹，每个月就是1.5亿的数据。

4.系统并发量较大

    每个订单会对应一条运单号，我们使用运单号去快递公司摘取物流轨迹，一般是后台使用定时任务去摘取（也有个别是快递公司推送过来的），根据业务对物流轨迹的实时性要求、系统的并发容量以及快递公司服务器的限流量做调整，刚开始定时器是8小时去拉取一次物流轨迹，后面调整成3小时。目前总共有24台服务器在跑，每天总共要拉取800万次物流轨迹。为了存放海量的物流轨迹，需要进行分表，分表的方式是根据快递公司的编码和运单号取哈希值，最后分成32个表。存放运单号的主表则不需要分表。同时订单号、运单号、快递公司编码、时间等字段加了索引，这样确保即使是上亿数据的表，在查询时也能很快就出来。

5.系统的稳定性要求较高

    如果系统挂掉了，或者没有及时从快递公司拉取到物流轨迹，就会影响业务的使用，甚至会影响订单结算（退货情况下）。但由于对接的各大快递公司的接口经常会出现各种状况，比如接口访问不了（对方系统升级或系统挂掉）、接口访问异常（HTTP响应超时）、接口限流、接口返回格式错误或出现变更、接口没有返回数据等问题都会导致轨迹拉取失败。虽然有日志告警系统对相应的问题进行告警，但处理起来依旧费时费力。